【レポート】”新しい常識”としてのクラウドコンプライアンス #AWSSummit

「クラウド時代のセキュリティポリシーとは何か、そしてそれをどのように変革、実践していくか」というテーマのセッションを聞きましたので、レポートします。

AWS Summit Online Japan 2020

#レポート

#AWS

#コンプライアンス

平野文雄

2020.09.09

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは HIRANO@おんせん県おおいたです。

いよいよ、AWS Summit Online Japan始まりましたね。

今回は、「クラウド時代のセキュリティポリシーとは何か、そしてそれをどのように変革、実践していくか」という内容のセッションを聞きましたので、レポートします。

セッション概要

アマゾンウェブサービスジャパン株式会社セキュリティアシュアランス本部本部長松本照吾

クラウドファーストやデジタルトランスフォーメーションを推し進める中、従来のセキュリティルールをそのまま適用しようとして、十分なクラウドのメリットを活かせない場合があります。本セッションではクラウド時代のセキュリティポリシーとは何か、そしてそれをどのように変革、実践していくかをお伝えします。

動画と資料

セッションの動画と資料はこちら

レポート

スピーカー: AWSJ 松本照吾さん

本セッションはだれのため？

イノベーションに即したポリシーを作っていく人（経営層、セキュリティ担当）
イノベーションに即したポリシーを評価していく人（監査人など）
ポリシーをつくる人とコミュニケーションする必要がある人（おそらく皆さん）

本セッションでの「ポリシー」の定義 - 規制や組織の基本方針・規程

"新しい常識"がなぜ必要なのか

"Cloud is the new normal and it's because builders now have control over their own destiny"
- Andy Jassy, CEO, Amazon Web Services が 2016 re:Inventで述べた言葉
- "new normal"="新しい常識" はリーマンショック後の構造変化から使われ始めた（COVID19から生まれた言葉ではない）
- AWSでは「Bulderたちが自分たちが望むものに対してコントロールを持てるようになった"new normal"」を発信し続けてる
新しい常識は外部および内部の課題の変化によって生まれてくる
- 競争。新しい技術、戦術の発展が源泉。
- 危機。COVID19、自然災害など。
ITやセキュリティをとりまく変化
- 仮想化
  - 物理管理から論理管理へ→伸縮可能なITインフラ
- クラウドサービス
  - IT所有からIT利用へ→ITビジネスモデルの変化
- DevOps
  - 厳密な職務分離から協働へ→内部統制モデルの変化
- サーバーレス
  - インフラ運用からサービス運用へ→責任範囲の変化
- ゼロトラスト
  - 境界防御からエンティティへ→信頼モデルの変化
従来の常識の単純な置き換えでは新しい世界に適応できなくなってきている
"新しい常識"を阻害するものはなにか？
- 常識を文書化したもの=>組織の説明責任の基礎としてのポリシー（組織の基本方針や規程）
- ポリシーは必ずしもテクノロジーの変化をフォローしない
  - 誰かが変えようとしなければ変わらない。静的なもの。
  - 変化が激しい環境においても、自動的に変わっていくものではない。
  - 決められたものを変えていくには、組織や人の努力が発生する
- ポリシーは肥大し、形骸化する。
  - たとえばBCP。過去の新型インフルエンザや災害などで、作られたポリシーがある。
  - 新たな危機で役に立っていないポリシー、見直しや削除が必要だが、そのままになっている。
  - 特にセキュリティ。新しい技術等に対するルールが増えていき、管理ができなくなり、硬直化・形骸化を招くリスクがある。
ポリシーの"トランスフォーメーション"
- "デジタルトランスフォーメーション"
  - 技術が変革を後押しする
  - 技術の採用や利用を支える組織の変革の必要性
- "ポリシー"の"トランスフォーメーション"
  - 技術や組織と同様に乗り越える必要がある
  - ポリシー自体がどのように新しい技術、新しい業務に適した形に変革していくか
  - ポリシーのあり方、運用をどのように変えていくかの視点が必要
- ポリシー運用の柔軟性が、"デジタル"の変革に大きく寄与する
ポリシーを変えていく方向性
- フィードバックやニーズを踏まえた変更のサイクル、運用の視点が必要
  - 硬直化したポリシーの運用は、"手段"にフォーカスしている。
  - 健全なポリシーの運用は、"目的"にフォーカスする。
- 目的にフォーカスすれば、新しい技術による新たな手段を柔軟に適用できる
日本においても多くの基準がこの考え方を適用
- 組織ごとにリスクアセスメントを行い、必要な管理策を選択し、適用していく
- 「とりあえずルールだから、全て網羅する」ではない
- 国レベル等大きな分野の規制でも、リスクベースのアプローチを重視
  - ISO/IEC27001
  - 金融機関等コンピュータシステムの安全対策基準第９版
  - 医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン
  - 政府情報システムのためのセキュリティ評価制度（ISMAP）管理基準

AWSにおけるセキュリティ・コンプライアンス

セキュリティ責任共有モデル
- セキュリティ自体の本質はクラウドであっても変わらない
- 責任範囲の違いからくる役割の違い、技術要素を踏まえた変化、には注意が必要
例:メディアの廃棄
- データのライフサイクルの統制として、メディアの破砕や消磁は一般的なセキュリティ統制
- 従来の管理策
  - 物理的なメディア破砕
  - ベンダの破砕における立ち合い
  - 廃棄証明書の取得
- AWSにおける廃棄
  - NIST 800-88に基づき、物理メディアの破砕を実施
  - 第三者による評価も実施
- AWSにおけるデバイス・データ管理の基礎
  - 仮想化技術のストレージ、特定顧客のデータが特定の物理デバイスに格納されるわけではない
  - 従来のような廃棄証明書は出せない=>従来型の統制は当てはめられない
  - 求めるべきセキュリティが守られていないわけではない
  - より高いセキュリティを責任共有の中で生み出していくことが可能
  - 暗号化やアクセスコントロールで顧客側で統制が可能
  - AWSにおける廃棄と合わせると二重にセキュリティの保護施策を実現できる

多層的なセキュリティ責任共有モデル

日本で多く取り入られている責任共有モデル
- AWS+パートナー+お客様
データの廃棄を通じてお客様が実現したいもの
- AWSの責任
  - インフラレベルでの分離
  - デバイスの破砕、消去
- パートナーの責任
  - データライフサイクルに応じた運用（データ利用の終了、記録の実施）
- お客様の責任
  - 説明責任、目的の明確化
    - 例：何のための統制
    - 例：個人情報利用目的の明確化
    - 例：保護を行うためのリスクの評価
- 目的に立ち返る:何のために"メディア廃棄"を行うか
  - コンテンツの第三者に対する許可のない開示から保護するため
- メディアの廃棄を待たずに、適切な利用終了を実装
  - ストレージを暗号化
  - 利用終了のストレージを削除
  - あわせて、暗号化に利用した鍵（CMK）を削除
  - ログを利用し、だれがいつ削除したかの記録を作成できる
  - 従来の廃棄証明をパートナーの責任範囲でで作成できる
- AWSブログでも紹介している
  - クラウドにおける安全なデータの廃棄
New normal: 成長する対象はすべてのStake holders
- AWS
  - フィードバックに基づくサービスの進化
- パートナー
  - ユーザの目的を踏まえたサービスの設計・実行能力
- お客様
  - 説明責任の根拠となるポリシーの管理

反復的なコンプライアンスの実践

多くの基準はリスクベースのアプローチを重視
- サービスや扱う情報によってセキュリティを扱う手段や程度は異なってくる
- 新しいサービスやシステムを実現する際に、目的にフォーカスをしてより柔軟に
反復的なコンプライアンスの実践
変化に強い柔軟なポリシーの設計
- AWS Well-Architected を例に
- 細かいレベルの実装基準を並べているわけではない
- 原則中心というアプローチ、抽象化された設計の基本原則を提示
- 何を選ぶかはお客様の責任（説明責任）
- セキュリティは"柱"のひとつ、目的に応じて選ばれるもの=>リスクベースアプローチの例
手段の目的化を避けるために
- ゼロトラストを例に
- 何のためにゼロトラストかするのか
- 運用上のオーバヘッドの評価など多面的な評価を
新しい"常識"から"良識"へ
- 何でも変化すれば良いというものではない
- 良識
  - "物事の健全な考え方。健全な判断力"
  - 本質を掘り下げる力

まとめにかえて

ポリシーの"トランスフォーメーション"
- 健全なポリシー運用は、"目的"にフォーカスする。
  - "デジタル"の変革は、ポリシーの運用の柔軟性にかかっている。
  - "手段"の目的かを防ぐために、フィードバックに基づき頻度を高く見直しを行う仕組みを組み込む。
Just one more thing
- "何かを学ぶためには、自分で体験する以上にいい方法はない。" by アルバート・アインシュタイン
- AWSを実際に触ってみる機会を強くオススメします